The most common Linux installation involves only a single screen, which is the system
console that came with the PC Linux is running on. If you are running your Linux system
for yourself and don't want to add another terminal to your system, your Linux
configuration is complete as far as terminals are concerned and you can skip this chapter.
If, on the other hand, you want to add another PC or a terminal to your system, either
for yourself to access (from another room, for example) or to provide access to Linux for
others in your home or office, you need to know how to add and configure terminals. This
chapter explains how to add terminals (including PC and Macintosh devices running terminal
emulation software) to Linux and how to configure them. It also explains how to use the
term program, which allows you to multiplex your serial lines, essentially supporting more
than one device on a line.
For the purposes of this book, the word terminal doesn't necessarily mean the old,
dumb, ASCII-based terminals that many feel are remnants of days gone by. Although those
machines are definitely terminals (and fully usable with Linux), modern terminals can
range from inexpensive graphics-based systems to complex X workstations that have more
in-built computing power than most PC machines (at a suitably hefty price). A terminal can
also be any other computer (PC, Macintosh, UNIX system, Commodore 64, Amiga, and so on)
that runs a terminal emulation package, which makes the machine act like a terminal.
You may want to add terminals to your system to allow other users to work with Linux at
the same time you do (it is a multiuser system) or to provide access to your database of
videotape movies (not to mention games) by running a terminal into your living room. If
you are a parent, you can run terminals into your children's rooms, letting them use the
system for education and entertainment. You may want to let friends access your system
when they visit, or call in over the modem.
For whatever reason you need new terminals, you can add them to your Linux system by
connecting them through an existing serial port on the back of your PC or through a
multiport card with many serial ports on it.
Because many PC machines have a maximum of four serial ports (and the majority of
systems only have two), expanding your Linux system using serial ports can be limiting. If
you use an external modem, a serial printer, or other serial port devices, you may not
have any serial ports left for terminals. In this case, you must use a multiport card.
Multiport cards are an easy and effective method of adding serial ports to a Linux
system. Multiport cards have a plug-in board that is placed in a slot on your PC system
and an oversized connector on the outer board edge to which a cable is attached. The cable
either leads directly to a number of serial ports (in which case the cable is called an
octopus) or to a hardware device that has serial ports laid out on it.
Multiport cards come in two basic types. The first is essentially a fast, somewhat
intelligent serial port server. These cards are inexpensive because they are simple to
manufacture. However, they lack any on-board processing or memory, so every device
connected to the multiport card takes its toll on the Linux system's CPU and RAM.
The other type of multiport card is the intelligent controller. These cards cost much
more, but have an on-board CPU to offload the Linux system's CPU. The on-board CPU can
handle all the communications requests and, in some cases, is smart enough to provide
terminal commands. These cards usually have RAM mounted on the board too, which provides a
cache system for speeding up access. In general, these intelligent boards are much better
for supporting four or more terminals and other devices than their dumber brethren, but
you may be spending money on features you don't need if you have less than that number of
attached devices.
Multiport cards can provide from 2 to 32 additional serial ports per card, and you can
add multiple boards to the increase capacity even further, although this situation is very
rare for Linux installations. A couple of manufacturers even offer systems that can
support 256 terminals spread out in a cluster arrangement. Some multiport boards include
parallel ports for printers, and a few high-end boards are designed to use SCSI devices.
Each port on the multiport card is usually wired for use by any serial device,
including terminals, modems, printers, scanners, and so on. However, a few cards designed
for simple terminal use support only a few of the wires in a serial port. These cards
cannot support modems, printers, and similar complex devices properly. Different card
manufacturers have different supported systems, so if you decide to go with a multiport
card for your system, check the specifications carefully.
The types of connectors on multiport cards differ, too. Most use either standard DB25
25-pin connectors or DB9 9-pin connectors, identical to the ones found as PC serial ports.
Some cards use the RJ45 connector, which looks like a wide modular telephone-style jack.
Adapters are used to connect the RJ11 connector to a standard serial cable. Again, if you
decide to use a multiport card, check the types of connectors and make sure the wiring of
the connector is consistent with your serial devices or that converters and adapters are
readily available.
If you are going to use a multiport card on your Linux system, make sure you use one
with software device drivers that are designed for Linux. You cannot use any multiport
card device driver designed for other versions of UNIX without modification. Because the
drivers are usually already compiled, you cannot modify the drivers yourself. Several
multiport card drivers, specially modified or written by Linux users to suit the most
popular multiport cards, are available from FTP and BBS sites. As Linux becomes more
popular, more multiport card vendors are developing optimized drivers for their products
to integrate with Linux.
Multiport cards come with complete instructions for installing the device drivers for
the multiport card, as well as configuring the terminals and other devices. Because the
details of the configurations change depending on the manufacturer of the multiport card,
you should consult the documentation accompanying your card for further information.
If you have a spare port, you can use your PC's serial ports to add terminals. In most
cases, connecting the terminal is a matter of running a cable between the terminal and the
serial port, and ensuring the proper connectors are used. You then update the Linux
configuration files to tell the operating system to provide service for the terminal. The
remote terminal should be active after this step.
You can choose any serial port for a terminal, although the port should not be shared
with other devices (such as a modem) unless you are willing to disable other devices when
the terminal is needed. If you need to run more than one device off a serial port, you can
get switch boxes to connect the devices to. These boxes usually have a rotary switch on
the front for routing the internal wiring to the proper port.
Serial port terminals are sometimes limited by the speed of the UARTs used in the PC,
although most new PC machines have the faster 16550 UARTs capable of high-speed
communications. Even older machines are very usable for all but graphics applications, as
most character-based terminals don't need speeds above 38,400 baud. (In fact, 9600 baud is
fast enough for most character-based applications, although 19,200 is better.)
The wiring of cables between the terminal and the Linux PC depends on the type of
connectors at both ends. The same problems usually occur whether you are using a serial
port or a multiport card for your serial ports. In most cases, the cables you will use
will be a DTE (Data Terminal Equipment) to DTE type. Some terminals and PC serial ports
require DCE (Data Communications Equipment) cabling. As a general rule, terminals and
remote computers use DTE, and modems use DCE. The difference between DTE and DCE cabling
is in the way the wires run from each end connector; DTE crosses several of the wires
between pins at either end.
Some store-bought cables are designed specifically for terminals and cross the internal
wires as part of their connector design, and other cables are designed for modems and have
wires that run straight through. If you find your terminal doesn't work even after
following all the configuration instructions discussed in this chapter, chances are your
cables are incorrectly wired. A null modem adapter (which forces a cross between wires) is
the easiest solution, and you can add it anywhere in the chain from the terminal to the
Linux PC.
A typical DCE cable (such as for a modem) uses straight through wiring, meaning that
pin 1 on the PC end goes to pin 1 on the modem end, pin 2 through to pin 2, and so on.
This cable is called a straight cable or modem cable.
DTE cables cross wires to allow sending and receiving ends accept signals on the same
pins, so that pin 2 in a connector is always for transmit, for example, and pin 3 is
always for receive. By crossing pins 2 and 3 between the two ends, one connector's
transmit pin becomes the other connector's receive pin. When connecting a terminal, some
of the pins must be crossed to permit signals to pass properly. The wiring of these cables
(often called null modem cables) requires several such crosses or shorts to make the
connection valid.
The sex of the connectors at each end of the cable is also important when buying or
making a cable. Carefully note whether the connectors at each end are male (pins sticking
out) or female (no pins). Usually, a PC has male serial port connectors (requiring a
female end on the cable), and a terminal has female connectors (requiring a male connector
on the cable), although if you are connecting a remote PC, you will need female connectors
at both ends. Multiport cards differ widely in their sex and types of connectors, so check
before buying cables!
Serial port connectors on a PC are either DB9 (9-pin) or DB25 (25-pin) D-shaped
connectors. Not all the wires in either the 9-pin or 25-pin connector are required for a
terminal. You can make a complete simple terminal cable with only three pins (send,
receive, and ground), although Linux also likes to use the Carrier Detect wire to tell
when a terminal is attached and active. Table 11.1 shows the important pins of 25-pin, DTE
connector cables and their meanings. The pin numbers change with 9-pin connectors, but the
crossings from one to another are the same.
Table 11.1. DTE cables for a 25-pin connector.
| Terminal Pin | Computer Pin | Meaning |
| 1 | 1 | Ground |
| 2 | 3 | Transmit Data / Receive Data |
| 3 | 2 | Receive Data / Transmit Data |
| 4 | 4 | Ready to Send |
| 5 | 5 | Clear to Send |
| 6 | 20 | Data Set Ready / Data Terminal Ready |
| 7 | 7 | Ground |
| 8 | 20 | Carrier Detect / Data Terminal Ready |
| 20 | 6,8 | Data Terminal Ready / Data Set Ready, Carrier Detect |
If the wiring of a cable is not clearly indicated and your terminal doesn't work at all, you may need to purchase a null modem device. A null modem device is a connector that has the pin crossings within it, effectively converting a straight through cable to a null modem cable, and vice versa.
Administering a Linux system requires you to know many of the small processes involved
in the kernel and device communications. One of the most important processes for users is
observing a login prompt on their screens and logging in to the system successfully. Many
users have no idea of the steps Linux goes through to provide a login prompt, so this
section examines that process. An understanding of the login process is also necessary to
know how to configure new terminals on your system, as several files must be modified to
support the new devices.
The login process begins when the /etc/init daemon (sometimes stored in /sbin/init) is
executed during the booting of the Linux system. The init process reads instructions from
the file /etc/inittab and executes them in order. Usually, the init daemon is responsible
for running a copy of the /etc/getty program for each terminal connected to the system.
Without a getty process, the terminal and kernel can't communicate.
The init daemon knows whether a terminal is connected because of entries in the
/etc/ttys and /etc/inittab files. The /etc/ttys file lists all ports on the system and the
type of terminal that is connected to them. The /etc/inittab file holds a complete list of
all terminals and their parameters. The section "/etc/ttys and /etc/inittab "
examines these files in more detail.
When the /etc/ttys and /etc/inittab files indicate that a terminal is connected and
active, the init daemon runs the /etc/getty program for that terminal. The getty program
sets the communications parameters for the terminal and displays the login prompt
on-screen. When a user logs in on a terminal, the getty process executes the login program
to request a password. The login program validates the username and password against the
entries in the /etc/passwd file.
If the login is validated properly, the login program displays the message of the day
(stored in the file /etc/motd) and executes whatever the user is supposed to run as a
startup program (usually a shell). As a final step, login sets the TERM environment
variable, then exits.
Terminal configuration information is stored in the /etc/ttys and /etc/inittab files.
The files are ASCII and can be modified by any editor, although you should be careful to
keep the proper format and not disrupt existing entries. Before making any changes to the
terminal configuration files, make a copy in case the changes you make are not effective
and the file cannot be returned to its original state easily.
If you don't want to edit these files manually, some menu-driven programs are available
that perform changes to the files for you based on a set of questions you answer. These
administration utilities tend to be a little slower than editing the files manually, but
they do ensure that the entries are in the proper format.
The /etc/ttys file is composed of two columns separated by any whitespace character.
The first column shows the type of terminal assumed to be connected and is used to set the
TERM environment variable. The second column holds the device name, less the /dev portion.
A typical /etc/ttys file from a new installation of Linux looks like the following:
console tty1 console tty2 console tty3 console tty4 console tty5 console tty6 vt100 ttyp0 vt100 ttyp1 vt100 ttyp2 vt100 ttyp3
You use the /etc/inittab file to set the behavior of each terminal. The format of the
/etc/inittab file follows this pattern:
ID:runlevel:action:process
The ID is a one or two character string that uniquely identifies the entry. For
terminals, this string corresponds to the device name, such as 1 for tty1. The runlevel
decides the capabilities of the terminal with the various states the Linux operating
system can be in. Run levels vary from 0 to 6. If no entry is provided, the terminal
supports all run levels. You can mention multiple run levels in the field.
The action indicates the behavior of the terminal device when the system starts and
when a getty process is terminated on it. Several valid entries for the action field apply
to terminals:
A simple /etc/inittab file showing terminal startup commands (taken from an earlier
version of Linux for clarity's sake, as the latest version complicates the lines a little)
looks like the following:
# inittab for Linux S1:1:respawn:/etc/getty 9600 ttyS0 S2:1:respawn:/etc/getty 9600 ttyS1
The lines indicate that a getty process should be started for ttyS0 (first COM port)
and ttyS1 (second COM port) at 9600 baud and should be respawned (restarted) if the getty
process terminates. You can use lines like these when you add terminals to serial ports.
Multiport boards usually use commands in different files to start their getty processes.
The /etc/getty program is referred to quite a lot when dealing with terminals.
Basically, /etc/getty is a program that sets the communications parameters between Linux
and a terminal, including the speed, protocol, and any special handling of the cable.
The /etc/getty program is called by /etc/init when the system boots or when the process
terminates. When called, /etc/getty opens the serial port or other connection to the
terminal and sets the communications parameters based on information in the file
/etc/gettydefs (getty definitions). The getty process then generates the login prompt on
the remote terminal. Many special handling and command options are available with the
getty process, but most of them are of little interest to users and casual system
administrators.
The /etc/gettydefs file supplies the settings getty uses for communications. The format
of each line in the gettydefs file is as follows:
label:initial flags: final flags: login prompt: next label
you use the label to identify each line so that when /etc/getty is started with an
argument (as it usually is, transparent to the user), the argument is used to match the
label and provide the configuration information. You use initial flags and final flags to
set any behavior for the connection before and after the login program has executed. The
login prompt is the prompt to be displayed on the terminal. Usually it is just login:, but
it can be any string unique to that terminal.
Finally, you use the next label to send getty to another line in case it can't use the
current one. This parameter is typically used with modem lines that start at a high speed
(such as 9600 baud), and then go to 4800, 2400, and 1200 in sequence, trying to connect at
each step. For terminals, the next label is usually a pointer back to the line's first
label.
An extract from a sample /etc/gettydefs file looks like the following:
console# B19200 OPOST ONLCR TAB3 BRKINT IGNPAR ISTRIP IXON IXANY
PARENB ECHO ECHOE ECHOK ICANON ISIG CS8 CREAD
# B19200 OPOST ONLCR TAB3 BRKINT IGNPAR ISTRIP IXON IXANY PARENB
ECHO ECHOE ECHOK ICANON ISIG CS8 CREAD #Console Login: #console
9600H# B9600 # B9600 SANE IXANY PARENB TAB3 HUPCL #login: #4800H
4800H# B4800 # B4800 SANE IXANY PARENB TAB3 HUPCL #login: #2400H
2400H# B2400 # B2400 SANE IXANY PARENB TAB3 HUPCL #login: #1200H
1200H# B1200 # B1200 SANE IXANY PARENB TAB3 HUPCL #login: #300H
300H# B300 # B300 SANE IXANY PARENB TAB3 HUPCL #login: #9600H
If you look at the file that accompanies your Linux system, you will see that there are
many more lines, but they all have the same format as the preceding examples. The easier
lines to look at are the shorter ones (the last five lines in the preceding extract).
These lines are for a modem starting at 9600 baud. The initial flag is set to B9600,
which sets the baud rate at 9600 baud. The final flags, used when a connection has been
established, set the characteristics of the line (such as a tab meaning three spaces).
Finally, the field at the end points to the next lower speed to provide checks for slower
modems or poor lines that prevent fast logins.
The first lines in the preceding extract are typical for the system console. They set
many initial and final flags that control how the console behaves. The reference at the
end of the line is back to the same definition, as the terminal is hard-wired to the
system. Terminals are defined in much the same manner, although their entries don't have
to be as complex as the console's. A few simple terminal definitions are as follows:
# 38400 fixed baud Dumb Terminal entry DT38400# B38400 CS8 CLOCAL CRTSCTS # B38400 SANE -ISTRIP CLOCAL CRTSCTS # login: #DT38400 # 19200 fixed baud Dumb Terminal entry DT19200# B19200 CS8 CLOCAL # B19200 SANE -ISTRIP CLOCAL # login: #DT19200 # 9600 baud Dumb Terminal entry DT9600# B9600 CS8 CLOCAL # B9600 SANE -ISTRIP CLOCAL # login: #DT9600
In each definition line, the baud rate is set with 8 bits (CS8) used. The flags are
used to set initial behavior. The login is a simple prompt, and the end of the definition
points back to the same line. These simple definitions in an /etc/gettydefs file suffice
for all dumb terminals, once you select the proper speed. If you are using a terminal with
more advanced capabilities, you can add those to the gettydefs file, too.
You may not have to change the entries in the default gettydefs file as it usually contains many different configurations. Examine the file carefully to find an entry that will work with the terminal you are using. If you do make changes to the gettydefs file, issue the command getty -c gettydefs to make the changes effective without rebooting.
The /etc/termcap file holds the instruction codes for the Linux kernel and getty to
communicate with different terminals. Most terminals that are supported by the Linux
operating system have an entry inside this file, so the file can be quite large. If you
are going to make changes, copy a version to a safe filename first.
Each entry in the termcap file has a name or label to identify the terminal it refers
to, along with several variations on the name, and then a set of codes and values for
different terminal characteristics. Because terminals use many different codes for
different actions, some of the more talented terminals use many codes.
An extract from a termcap file shows the definitions for two fairly simple terminals,
the Wyse 30 and Wyse 85:
w0|wy30-vb|wyse30-vb|wyse 30 Visible bell:\
:vb=\E`8\E`\072\E`9:\
:tc=wy30:
wc|wy85|wyse85|Wyse 85 in 80 column mode, vt100 emulation:\
:is=\E[61"p\E[13l\E>\E[?1l\E[?3l\E[?7h\E[?16l\E[?5W:\
:co#80:li#24:am:cl=\E[;H\E[2J:bs:cm=\E[%i%d;%dH:nd=2\E[C:up=2\E[A:\
:ce=\E[0K:cd=\E[0J:so=2\E[7m:se=2\E[m:us=2\E[4m:ue=2\E[m:\
:ku=\E[A:kd=\E[B:kr=\E[C:kl=\E[D:\
:kh=\E[H:xn:\
:im=:CO=\E[?25h:CF=\E[?25l:ic=\E[1@:dc=\E[1P:\
:dl=\E[1M:al=\E[1L:GS=\EF:GE=\EG:pt:
The meaning of each set of codes is not really of interest to most users and system
administrators. You only have to start changing or rewriting terminal entries if you are
adding a terminal type that does not exist in the termcap file already.
Most terminals offer multiple emulations. If you can't find the terminal type you need in the termcap file, look for an emulation that is supported (usually a Qume, VT, or Wyse type). It is easier to emulate a different terminal than write a termcap entry for a new type.
The /etc/ttys file uses the terminal characteristics in the /etc/termcap file. The
first column of the ttys file gives the default terminal type used to set the TERM
environment variable. The startup routine uses a pattern-matching utility to find a
matching line in the termcap file, and then reads the codes that follow and uses those for
all communications.
Terminals are added to Linux in much the same manner as other devices, though the mknod
command. To add a terminal, you must know name of the port to which the terminal will be
connected. Linux refers to the serial ports on a PC as /dev/ttyS0 (for COM1), /dev/ttyS1
(for COM2), and so on.
Most PC systems have one or two serial ports, although up to four can be accommodated
on a PC (/dev/ttyS0 to /dev/ttyS3). Linux uses the serial ports based on their addresses
in the BIOS. The usual addresses for the serial ports are as follows:
| ttyS0 (COM1) | 0x03f8 |
| ttyS1 (COM2) | 0x02f8 |
| ttyS2 (COM3) | 0x03e8 |
| ttyS3 (COM4) | 0x02e8 |
If you are not sure about which serial port is which, you may have to either use a
DOS-based diagnostic utility (like MS-DOS' MSD.EXE or a commercial package like Norton
Utilities or Central Point Tools) or start at the lowest address and work up, testing the
terminal each time. If the PC has only one port, it is almost always configured as COM1
(/dev/ttyS0). The Linux installation script usually configures the two PC serial ports, so
you may only need to set the speeds and parameters for a terminal attached to a serial
port. If you are using a multiport board, you will probably have to install drivers.
To create a new terminal device, you must run the mknod (make node) command to create
the new device driver file, and then change the permissions on the file to let root or a
root-started daemon run it. A typical command for creating a new terminal device is
mknod -m 660 /dev/ttyS0 c 4 64
where the -m 660 sets the permissions on the file, /dev/ttyS0 specifies the first
serial port on the machine (COM1), the c indicates that the terminal is a character mode
device (almost all terminals, except very high-speed high-end models are character
devices), and the major and minor device numbers are set to 4 and 64, respectively. For
the other serial ports on the PC (COM2 through COM4), the commands would be
mknod -m 660 /dev/ttyS1 c 4 65 mknod -m 660 /dev/ttyS2 c 4 66 mknod -m 660 /dev/ttyS3 c 4 67
The changes in the minor device number with the different commands above are required,
although you can use any number you wish. The only requirement is that there must be a
unique combination of major and minor device numbers for each terminal.
After the mknod command has been executed, you must set the device driver to the proper
ownership. Issue the command
chown root.tty /dev/ttyS0
to set the ownership of /dev/ttyS0 (or whichever port you are working with) to
root.tty, a special Linux ownership for the device driver files that provides the startup
daemons with access.
You also need to change the entry in the /etc/ttys file to include the terminal type
and device you have added so that the startup of the terminal can be performed properly.
Because the /etc/inittab file already contains entries for the standard serial ports, you
can edit the entry for your new terminal's port, if necessary, to set the baud rate and
other parameters that may be required.
The stty command enables you to change and query a terminal option. The stty command is
very complex, with dozens of options that modify the behavior of the terminal device
driver. Luckily, only the most intense system administrators have to use the many options,
so this section ignores most of the details. If you are curious, check the man page for
more information.
To see the current settings of a terminal, use the stty command without any arguments
or with just the device name, such as
stty /dev/ttyS1
The stty utility displays a set of parameters that indicate how the terminal is
configured. You can use this information to verify that the terminal has read the
configuration information properly from the /etc/inittab and /etc/gettydefs files. If the
parameters don't match, check the configuration files to see whether there is a
typographic error (very common) or an illegal command.
Like stty, the tset command has many options, most of which are seldom used (especially
if you are not dealing with strange terminals and weird connectors). The tset command is
used to initialize the terminal driver with a terminal's command set. If the tset command
is given with a specific argument, it uses that. Otherwise, it uses the value defined in
the TERM environment variable.
You can use tset within the startup files of a user who always logs in from a remote
terminal (through a modem) to force a particular configuration, saving a few setup
commands. If you put the command
tset -m dialup:vt100
in the shell startup file (.profile, .cshrc, and so on), the terminal type will be set
to vt100 every time a connection is made through the modem. Of course, this command sets
the terminal type even if someone isn't using a VT100 terminal. You can use the command
tset -m dialup:?vt100
to have the user connecting through the modem prompted for the terminal type. The
prompt will look like the following:
TERM=(vt100)?
If the user presses Enter, the TERM variable is set to vt100. If the user doesn't want
to use that value, the user can enter the correct string at the prompt.
In the examples shown so far, tset seems to be quite simple, but it has a very complex
structure when dealing with hardwired terminals. To properly configure a terminal
connected through a serial port, you need a command like the following:
eval `tset -s -Q -m dialup:?vt100 -m switch:z29`
The full details of this type of command are unimportant for most system
administrators. If you want more information, check the man pages for tset and stty that
came with your Linux system.
Every now and again a terminal connected through a serial port starts acting screwy,
either not showing a prompt or generating garbage. There are two quick ways to try to
reset the terminal. If they don't work, you should shut down the terminal and restart it.
(You may have to kill the processes that were running on the terminal.)
The first approach is to issue a set of Ctrl+J characters on the screwy terminal, and
then type stty sane followed by another Ctrl+J. The command stty sane should reset the
terminal characteristics to normal (rereading the terminal characteristics from the
configuration files). You probably won't see the letters you are typing, so enter them
carefully. If you make a mistake, start the process again with a couple of Ctrl+Js. If the
terminal isn't behaving at this point, type reset and press Enter or Ctrl+J. If this
action doesn't work, you should reset the terminal manually.
Often, a problem with a terminal is not with the Linux software but the terminal
itself. You can easily cure this type of problem by turning off the terminal, waiting a
few seconds, and then turning it back on. If the problem was a terminal character code,
the terminal should behave immediately. If it doesn't, check the processes running on the
main Linux machine; there may be a hung process or runaway routine. You can kill the
processes for that terminal and restart it.
The term program, which was developed by Michael O'Reilly, is included with many
versions of Linux and is readily available on FTP and BBS sites. This program enables you
to multiplex your serial lines so that you can support more than one device on a line. You
can, for example, use the same serial port to control both a terminal (including an X
terminal) and a modem simultaneously. The general process for working with term is to log
in to a remote machine normally, run the term program on the remote, and then run term
locally. Once the two term processes are properly talking, you can use the same line for
your terminal and modem sessions, transferring files while you continue to move around the
remote filesystem.
Although term shares many of the features of more complex TCP/IP protocols such as PPP
and SLIP, it is unique in that it requires no kernel drivers. The term program functions
by essentially making your serial port into a service port, much as SLIP and PPP do. The
program manages the connection requests coming into the serial port and can maintain
multiple processes through that port. The machine on which the serial port is based,
called the server, can talk to other machines or peripherals (the clients) through the
serial port protocol term imposes.
Most Linux distributions include a compiled version of the term utility, so you don't
have to compile the program. If you have only source code, you must compile it using the
make utility. Each distribution supplies instructions for compiling term. Several versions
of term are currently available, and each version has slightly different compilation
processes and requirements. Check the documentation carefully before you begin the
compilation.
The term system requires you to set a number of environment variables. Because any
system user can run term, these variables should be defined for each user in the user's
startup files. If the root login wants to use term, the environment variables must be
defined in the root startup files. The environment variables that are important to term
are as follows:
For versions of term prior to 1.16, only the TERMDIR environment variable is necessary because these versions do not support private and shared mode.
The commands needed to set the environment variables differ depending on the shell you
use. The TERMDIR variable is usually set to your home directory, so it is defined in the
following manner for the C shell or compatible (including tcsh) in the .cshrc or .login
file:
setenv TERMDIR $HOME
In the Bourne and Korn shells (and their compatible shells), this variable is defined
in the .profile file using the following lines:
TERMDIR=$HOME export TERMDIR
You can explicitly define the directories if you want, as in the following example:
setenv TERMDIR /usr/tparker/termdir
If you are running a version of term later than 1.15, term supports shared and private
usage. Define the TERMMODE variable in the same startup location as the TERMDIR command.
For the C shell and compatible shells, use the following line if you want to run in
private mode:
setenv TERMMODE 0
For the Bourne and Korn shells (and compatibles), you can set term to run in private
mode with the following lines:
TERMMODE=0 export TERMMODE
If you want to run in shared mode, set the TERMMODE variable to a value of 1, and
define the TERMSHARE variable to show where the shared directory is, as in the following
examples for the C shell:
senenv TERMDIR /usr/tparker/term setenv TERMMODE 1 setenv TERMSHARE $TERMDIR
The following commands are examples for the Bourne and Korn shells:
TERMDIR=/usr/tparker/term TERMMODE=1 TERMSHARE=$TERMDIR export TERMDIR TERMMODE TERMSHARE
Versions of term later than 2.0.0 also have an environment variable called TERMSERVER
that must be defined when there is more than one modem and the modems can be used
simultaneously. This variable tells term which modem line to use for which connection
name. The variable is defined with the name of the connection. Suppose you were setting up
three modems and three connections (called conn1, conn2, and conn3) for the C shell. You
would add the following line to the startup file to tell term to use Conn1 for its
connection:
setenv TERMSERVER Conn1
For the Bourne and Korn shell, you would use the following commands:
TERMSERVER=Conn1 export TERMSERVER
When the term command is started in these cases, the connection name must be specified
as well. For example, with the above configuration information, you would start term with
the command:
nohup term -v /dev/modem1 Conn1 &
This command line applies only to those systems with multiple modem connections using
term.
After you add the term environment variables to the startup files (and you have logged
out and back in to make the changes effective), you can test the term daemon and its
configuration. The term program uses a daemon running in the user's memory space to manage
the simultaneous demands placed on a serial port.
A test program is included with most versions of term. If the test utility is not
compiled and you have a C compiler present on your system, you can compile the program
with the following command:
make term
In some distributions of Linux, the test program is already compiled. If you don't have
a compiled version or a compiler, you can either search the BBSs and FTP sites for a
compiled copy, or skip the testing step and start the term program (hoping for the best
while you do so).
When the test program is available, run it at the command line by typing the utility's
name (you should be in the directory term resides in to avoid confusion with the shell
test command):
./test
When test starts, issue the following command to test the upload capability:
tupload ./test /tmp
This command places a copy of the test utility in the /tmp directory.
All local output from the term program is stored in the file local.log, and the remote
output is stored in the file remote.log. You can examine these files if you run into
problems or want to check the status of a session. You can force debugging information to
these files by starting term with the following option:
-d255
This option is handy if you have been experiencing problems and want to see the log of
all transactions.
Another utility supplied with the term package is linecheck, which is useful for
testing the transparency of a connection. The linecheck utility sends each of the possible
256 ASCII characters (8-bit characters, of course) over the link and verifies that they
are transferred properly.
To use linecheck, you should be connected to a remote terminal using any communications
package you want, such as kermit (see the procedure for using term explained in the next
section). Once you have established the connection between remote and local sites, switch
to the remote machine and issue the following command:
linecheck linecheck.logfile
This command places all output of the linecheck utility in the file linecheck.logfile
in the current directory on the remote system.
Then switch back to your local system and escape from the terminal mode. If you stay in
terminal mode, the terminal software will misinterpret many of the characters linecheck
generates. After you escape from terminal mode, issue the following command:
linecheck linecheck.logfile > /dev/modem < /dev/modem
This command tells linecheck to save results in the file linecheck.logfile (in your
current directory on the local system) and take all input from the modem port and send all
output to the modem port.
When the linecheck utility has terminated, examine the file linecheck.logfile on both
the local and remote systems. There may be a set of numbers at the bottom of the file that
linecheck has determined your system can't transfer. These numbers must be specified in
the term startup file called termrc in order to prevent future problems.
For example, if the linecheck utility determines that it cannot send the character with
ASCII value 200 from the local to remote system, but that this value transfers properly
from the remote system to the local system, place the following line in your local
system's termrc file:
escape 200
On the remote system, you must add the following line to tell the remote to ignore that
ASCII value:
ignore 200
For each escape command on one system, there should be a matching ignore command on the
other!
There will probably be several characters that can't be handled both ways, primarily
because some of the valid ASCII characters are reserved by the communications software as
escape characters to get you between modes.
If you can't get proper output from the linecheck utility, the XON/XOFF protocol is
probably getting in the way. You can disable this command and rerun the linecheck utility
with the following command:
linecheck linecheck.logfile 17 19 > /dev/modem < /dev/modem
The term utility is started both on the remote system and on the local systems, which
means you must have copies of it properly configured both locally and remotely. Because
you will want to transfer files with term, it is best to run in 8-bit mode. Start up your
communications software and make sure your serial ports are set for 8-bit characters.
To use term, log in to the remote system and start up term. A useful command syntax to
start term is the following:
exec term -l $HOME/termlog -s 38400 -c off -w 10 -t 150
Although this command line may seem like a lot to type, it includes the most useful
term options. You can place it in a script file or alias it (with shells that allow
aliasing) to make starting the term process easier.
Use the exec command to replace the currently running shell version on the remote with
term. If you don't use exec, you leave your shell running on the remote machine, which
ties up memory and process time for nothing. If you are in the process of debugging a term
connection or want to terminate term at some point during your session, don't use the exec
command in front of term.
The -l option specifies a log file for errors. In this case, all error messages are
saved in the home directory in the file termlog. You can leave off the entire option if
your term session is behaving properly and switch it on only after you have encountered a
problem.
The -s option specifies the speed at which to run the connection. This speed should
match the speed of the modem with any on-the-fly compression systems active. For example,
38400 baud is usually possible on most 14.4kbps modems that use compression. If the speed
rate is set too fast, you may lose characters. Slow down the connection if necessary. Note
that most PC machines require a 16550 UART for speeds higher than 9600 baud.
The -c option turns off data compression built into term. Because this command line
represents a 14.4kpbs modem with inherent compression, the term compression is turned off
to prevent double compression, which doesn't gain anything for performance. If your modem
speed is 9600 baud or slower with no inherent compression, use the -c on option instead to
active the term compression algorithm. Compression must match at both ends of the
connection.
The -w and -t options are used to optimize a fast link over a 14.4kbps (or faster)
modem. They set the transmission sliding window and timeout parameters. Usually, these
settings are fine and need not be altered.
After establishing the remote term session, escape from your communications software to
a local session and start term on your local machine with the following command:
term -r -l $HOME/logfile -c off -s 38400 -w 10 -t 150 < /dev/modem > /dev/modem &
The options mean the same thing as they did for the remote process. You must add the -r
option on one end of the connection, or term will instantly die. This option sets one end
of the connection as the server and the other as a client. As shown in the above example,
you can run the entire command (which is best saved in a script or alias) in the
background, which enables you to use the terminal window for other things. The term
program executes without any problem in the background.
Now term should be functioning properly. If you experience problems, examine the log
files or run the test and linecheck utilities to isolate the problem. If the connection
works but is very slow, check the log files to see whether they contain timeout messages.
If they do, double check the configuration because that is the most likely source of
problems.
The connection may seem a little jumpy (characters coming in bursts), but that is
normal, especially when compression is active. For most purposes, the term session is much
slower than a normal login to a remote. The real advantage to term is when you are
transferring files at the same time you are moving about on the remote system.
To terminate term, you can force a fast destruction of the connection by killing the
process on both ends. A better approach, which properly closes the connection, is to issue
the following command:
echo '00000' > /dev/modem
As long as the string you send has five zeros, the connection will close properly. Some
versions of term include the command tshutdown, which closes the term session for you.
Check the distribution software. If your term version is 1.14 or higher, tshutdown should
work.
You can use the term utility from within an X terminal window. X (or XFree86 with most
versions of Linux) enables you to open a window specifically to run term. Most of the X
connection handling is with a utility called txconn. You must execute the txconn program
on the remote machine (connected over a network, as X doesn't work with any reasonable
degree of speed over a modem) and place it in the background as a daemon. When txconn goes
to the background, it returns a message containing a display number that identifies the
process:
Xconn bound to screen 11
When you connect to the remote txconn daemon from an X window, you use this number to
identify the screen. You identify the screen by using the DISPLAY environment variable. If
the binding was to screen 11, as shown in the preceding message, you would set the
variable to
setenv DISPLAY remotename:11
where remotename is the name of the remote machine (for the C shell). With the Bourne
or Korn shell, you set the same environment variable with the following commands:
DISPLAY=remotename:11 export DISPLAY
When the term client is started in the local X window, it will connect to screen 11 on
the remote machine. Because txconn knows about screen 11 on the remote, all X instructions
will be transferred to the local machine's X window.
If txconn doesn't allow you to connect or you get permission messages, you may have to issue the command xhost + on your local machine to allow the remote to open and control a window on your local session. This form of the xhost command allows any remote machine to access your windows. If you want to be sure only the remote server can open windows, use its machine name in place of the plus sign, such as xhost merlin. Alternatively, use the xauth command to control access. See the xauth man page for more information.
You can run the local machine with windows opening on the remote system's X session
using txconn, but a better approach is to use the tredir command, which is covered in the
"Using term Utilities " section.
Running X sessions over a modem using txconn is possible, although the high amount of
traffic X involves can bring even the fastest modem to a crawl. A local area network
connection has enough speed to sustain X window traffic. A low-overhead version of X
called LBX is available for some platforms that may help solve the overhead problem for
modems. Also useful is a utility called sxpc, which compresses X protocol packets for
transmission over modems. You can get sxpc with some versions of term, and it has worked
well with 14.4kbps and higher speed modems, although performance is predictably slow.
The term software comes with a number of utility commands for handling file transfers.
The utilities vary depending on the version of term. All these utilities require a term
link to be established and functioning before you can use them.
The utilities that generally accompany term are the following:
The tredir utility is a powerful tool and can be used to good advantage with term. The
tredir program runs as a daemon in background and provides port services (much like other
networking daemons). The tredir daemon monitors ports and forwards requests from the term
remote. The tredir daemon redirects network services over the term link. The tredir system
works with modems and over networks.
To show how tredir works, suppose you want to redirect a local serial port to the
Telnet port on a remote machine (ports are assigned for specific protocols and services).
To redirect local port number 2024 to remote port 23 (the Telnet port on the remote
machine), issue the following command:
tredir 2024 23
Now whenever you use port 2024 on the local machine, it is redirected to the Telnet
port on the remote. To connect to the local port 2024, you could use the telnet command.
The following output shows that you access the remote Telnet port when you issue the
telnet command from the shell prompt (the remote machine's name in this example is
brutus):
$telnet localhost 2024 Trying 147.92.142.1 Connecting to brutus... login:
So you have redirected the Telnet session, but what good is this action in the normal
course of events? It is quite useful when you want to redirect output to machines for
reading e-mail, news, databases, accessing the Internet, and so on. Suppose you have a
corporate e-mail server. You could use tredir to set up a direct link to the server's
Telnet port, and then easily access that machine directly from your local machine without
worrying about protocols, windows, and so on.
One sneaky way of using tredir is to open X windows on a remote machine from your local
machine. This technique relies on the fact that X uses a set of ports for protocol
communications. An X server software package waits for instructions on a port number given
by the following formula
port=6000+display_number
where displaynumber is the number of the window on the X session. For example, X window
number 8 listens for instructions on port 6008.
If you want to open a window from your local X session on a remote X server, you can
use these port numbers and tredir. The process involves mapping a local window onto an
unused window on the server. For example, the command
tredir 6008 brutus:6004
establishes a redirection between the local X window identified by port 6008 (which is
on your local machine) to the remote X window given by port 6004 (the remote machine's
name is brutus in this example). Do not use 6000 as a port number because it is the root
console of all X sessions. Instead, pick a higher number.
After you issue the tredir command, establish your DISPLAY variable to point to the
port that is being remapped on your local machine:
setenv DISPLAY localname:8
This C shell command sets your display default to the local machine's window number
eight (which is remapped through tredir). Of course, you should put your machine's name in
the command.
Finally, when you issue the xterm command on your local machine, it should open a
window on the remote machine for you. If this command doesn't work, it's because of
restrictions on the remote machine. Run the xhost + command when logged in as root to
solve the problem, or use the xauth command to establish your machine as authorized to
open windows.
Finally, some term-friendly utilities are available in Linux FTP sites, including
versions of FTP, Telnet, and Mosaic. Check with the local distribution software sets, as
well as FTP and BBS sites to find out which utilities have been modified to work with term
if you plan to use term as a primary utility.
Although few systems will have terminals hanging off them, running several terminals
from a single PC is a great way to share the resources of your system. It makes it very
handy when two or more people want access, especially for games!
This chapter has shown you the basics of handing terminals with the Linux system. The
information presented applies to most versions of Linux, although there may be some slight
changes in options and arguments as the different utilities are enhanced or streamlined.
If you want more information about any of the commands mentioned in this chapter, refer to
the man pages and other documentation that came with Linux.
The term package is a powerful, easy-to-use utility that lets you simplify many file transfer and remote session actions when you can access a remote Linux machine also running term. Once you have set the environment variables term requires, it operates quickly and easily. Check for new releases of the term package periodically; the authors and other programmers are always adding new features and software utilities.
